As a network transport protocol, the Real-Time Transport Protocol (RTP) was published by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) in 1996. RTP specifies standard formats for audio and video data packets on the Internet and lays a technical foundation for the Internet Protocol (IP) telephony industry. As a profile of RTP, Secure RTP (SRTP) provides privacy and integrity for RTP. SRTP does not support the function of algorithm negotiation and key exchange. In general, the function is implemented by signaling protocols or other key management protocols. According to latest research achievements, in-band key negotiation based on Datagram Transport Layer Security (DTLS) in point-to-point RTP sessions is widely recognized.
In the key negotiation solution in the prior art, the negotiation function is performed over a signaling channel; that is, the security policy of SRTP is carried by a signaling channel. The sender of an SRTP multicast session (hereinafter referred to as the sender) uses the Session Announcement Protocol (SAP) or the Session Initiation Protocol (SIP) to invite each receiver of the SRTP multicast session (hereinafter referred to as the receiver) to set up an SRTP session. The signaling protocol carries the descriptor of the Session Description Protocol (SDP) to describe the security policy of SRTP.
The prior art, however, exhibits the following weaknesses:
First, the early arrival of content exists, which also exists in the point-to-point signaling solution. The main cause for the early arrival of content is that the key stream is asynchronous with the real-time data stream. In actual applications, the real-time data stream and key stream are transmitted through different paths and the transmission delay cannot be accurately determined because different quality of service (QoS) polices are used. Thus, the encrypted data may arrive earlier than the confirmation data for security policy updating. The key is not loaded to the SRTP stack. Thus, the encrypted data stream that arrives earlier cannot be normally decrypted. This causes data interruption and potential security holes and affects the quality of the user experience.
Second, the solution is related to the specified implementation solution. For an SRTP multicast session, for example, in a multicast conference, the receivers join the multicast group through the Internet Group Management Protocol (IGMP) to receive the multicast data. In this case, the multicast system does not require out-of-band signaling negotiation and the key negotiation based on out-of-band signaling is limited to the specified implementation mode.
Finally, in this solution, the trusted terminal may be indefinite in a complex multi-terminal system. In actual applications, the called terminal (a receiver) may be connected to one or more other terminals (other receivers) through a SIP proxy server. The connected terminal may not have the right to join the RTP multicast session but may listen to the encrypted SRTP multicast session through the key carried by SIP.
Thus, the key negotiation solution in the prior art cannot realize safe negotiation about the security policy of SRTP multicast sessions. For example, the content may arrive earlier; the solution is limited to the specific setup modes of RTP multicast sessions; and the trusted terminal is indefinite.